Communication resource management is an important feature in commercial wireless communication networks, because it enables Quality of Service (QoS) provisioning, good network utilization etc. Traditionally, QoS has been a crucial feature to guarantee predictable user experience for fixed bitrate services such as voice communication, which is the reason why reservation of resources, different quality of service classes are used in the UMTS access network (UTRAN).
Data communication—in most cases: Internet communication—is normally treated as non-GBR traffic, i.e., traffic that does not require guaranteed bitrates and strict resource reservation. This is based on the assumption that such traffic would use transport protocols such as TCP (Transmission Control Protocol) that is generally able to adapt to changing path characteristics.
The increasing popularity of wireless Internet services has led to a significant increase of data usage in UMTS, and further increases are expected for LTE networks. With regard to LTE networks and E-UTRAN see 3GPP TS 36.401. For the deployment of LTE with its increasing data rates, managing increasing volumes of non-guaranteed bitrate traffic—non-GBR, best effort data traffic—with satisfactory user experience is becoming a daunting task for the mobile operators. Because of the popular and ubiquitous flat-rate data tariffs and the proliferation of wireless USB (Universal Serial Bus) adapters for portable computers, there is no incentive for users to use the network responsibly, which leads to unrestricted network usage, high load and thus often sub-optimal overall quality of experience for non-GBR traffic.
One of the problems is that a heavy user, e.g., using P2P (Peer-to-Peer) file sharing, can significantly impact the quality of experience of other users (as long as their communication session are sharing resources). For elastic data traffic there has long been a conception in the Internet community that TCP, the dominant transport protocol, provides the necessary fairness, as its congestion control algorithm reacts to observed congestion by reducing the sending rate, which would normally lead to a “fair” distribution of the available bandwidth between competing TCP flows. However, the notion of per-flow fairness is more an implicit property of the congestion control, and it operates on the flow level and cannot take multiple flows per users into account. A user with N active flows could therefore use a significant higher fraction of the available bandwidth compared to user with only 1 active flow. Also, it can obviously not consider long-term behavior of users, see Flow Rate Fairness: Dismantling a Religion, Bob Briscoe (BT & UCL), ACM Computer Communications Review 37(2) 63-74 (April 2007), because it applies to resource distribution at a certain point in time only. Hence TCP congestion control is not an effective mechanism for achieving any kind of fairness and cannot provide any form of long-term fairness between users with respect to communication resource usage in wireless access networks.
To have at least some means of controlling resource usage, operators apply other techniques, e.g., monthly volume limits and a different treatment of specific applications such as P2P and VoIP (Voice over IP). This per-application control is often implemented traffic management based on Deep Packet Inspection (DPI), see http://en.wikipedia.org/wiki/Deep_packet_inspection. DPI can increase the average satisfaction level of the users by inspecting the transport and application layer protocol headers and make educated guesses about the user preferences for different types of traffic. The operator then implements policies that are intended to improve the application performance without any involvement of the end-systems or users. However, not all users will be satisfied by the policies implemented, and countermeasures may be taken to avoid the policies. Moreover, this approach is considered problematic because of its complexity and also with respect to on-going changes in legislation and regulation with respect to net neutrality.
Another fundamental problem within DPI is that, while it is in general possible to limit the available bandwidth for users—either generally, after they have exceeded their monthly volume, or specifically for certain applications—this is a rather inefficient way of resource management, because traffic is limited regardless of the current network utilization. Even if—at a certain time—sufficient capacity for running P2P applications would be available, this cannot be used because of the rather static limits. Fundamentally such solutions do not recognize that high-bandwidth/high-applications are not a problem in general—the actual problem is congestion, and for scenarios where congestion occurs, resource management and accountability mechanisms should be in place to enable a better overall usability of the network.
One of the approaches that address this problem is the Re-Feedback concept, see Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C., Salvatori, A., Soppera, A., and Koyabe, M. 2005. Policing congestion response in an internetwork using re-feedback. SIGCOMM Comput. Commun. Rev. 35, 4 (October 2005), 277-288, which is based on the notion of accounting for congestion—and not for traffic volume. The fundamental idea is that network elements are able to detect congestion events and apply congestion marks onto data packets that are sent from a sender to a receiver, e.g., using TCP as a transport protocol. These congestions marks reach the receiver, and the receiver is able to convey this information—as congestion feedback—back to the original sender by leveraging a return channel of a transport protocols, e.g., acknowledgments in TCP. The congestion feedback has the semantics of observed contribution to the path congestion by a specific flow. The sender is able to re-act to this feedback, e.g., by reducing the sending rate. But more important, the Re-Feedback concept stipulates that the sender uses this feedback to declare its contribution to congestion to the network by adding some information to the sent packets in the next round-trips.
The network—e.g., policing entities—can use this congestion declaration to account for congestion per user (or per flow) and apply policies based on that. E.g., such a policy could enforce a certain congestion-budget per month; once this has been reached, no further contribution to congestion is allowed, i.e., packets of that user would be dropped preferentially when there is congestion. As a consequence, users get a clear incentive to use the network responsibly—by receiving negative feedback when they contribute to congestion.
The Re-Feedback concepts as described in Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, C., Salvatori, A., Soppera, A., and Koyabe, M. 2005. Policing congestion response in an internetwork using re-feedback. SIGCOMM Comput. Commun. Rev. 35, 4 (October 2005), 277-288, have been implemented as a concrete specification for IP networks called Re-ECN (Explicit Congestion Notification) in http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09 (Internet Draft, work in progress). In addition to a specification of packet marking syntax and semantics, Re-ECN specifies specific network elements and their behavior in http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-motivation-02 (Internet Draft, work in progress). An overview of the required elements is depicted in FIG. 1.
The following network elements are involved:                Sender S: sending IP packets, using transport protocol with feedback channel, understanding ECN marking semantics, supporting Re-ECN-based congestion declaration;        IP router R1, R2 and R3 with ECN support: marking IP-packets based on observed congestion for egress queue;        Receiver R: receiving IP packets, using transport protocol with feedback channel to convey accumulated congestion information;        Policer: traffic-policing entity that uses information from congestion exposure to police user traffic and to account for user traffic; and        Dropper: enforcement entity ensuring correct congestion declaration.        
Once a router (for LTE eNB) marks a packet for indicating congestion, it set bits in IP packet, and this bit sequence is called CE (Congestion Experience). For better illustration, a CE-marked packet is called a “red packet” in the context of congestion exposure.
For reference, there is provided the following explanation:
Red Packet=CE code point (accumulated red packets represent the congestion fraction). Black Packet=Re-Echo code point (accumulated black packets represent the congestion response fraction). White Packet=ECT code point. That neither carries congestion information nor the response information. A complete description of this scheme is available at http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09.
The different packet marking options are symbolized by different colors in this description: red packets are congestion-marked packets, i.e., marked by IP routers with ECN support, and black packets are congestion-declared packets, i.e., packets that have been marked by a sender, based on the received feedback from the receiver. White packets do not carry congestion nor response information.
The policer is placed at the ingress of the network, close to the sender, where traffic originating from different sources has not been mixed yet. The sender declares path state congestion by inserting black packets into the flow. The policer acts as a rate limiter for black packets. Each packet is examined before it is accepted into the network. It implicitly defines an upper bound on congestion that a user is allowed to cause in network: e.g. congestion quota over a time period. Potentially, if a sender is exceeding its congestion quota, a policer may start dropping packets from that flow.
How exactly a policer is implemented is a prerogative of the network operator. Various types of policies could be defined for various types of customers. Policing could be implemented on per user or per flow basis. An instance of policer is instantiated depending on how accountability is needed.
In addition to the policer, there is another entity, called dropper, that is responsible for enforcing that senders declare their congestion contribution correctly. The goal of re-feedback mechanism is balancing on average red and black packet fractions closer to receiver. Senders may try to cheat the system by being dishonest when declaring the path congestion, i.e. by not inserting a number of black packets that correspond to the number of white packets it has been informed about. Therefore the re-feedback framework contains a dropper that should catch malicious senders by maintaining some state about flows in the dropper which is located close to receiver.
If the difference on average, between black and red fractions is persistently—over time—positive in a particular flow, it implies sender is taking a stronger congestion response by sending more black packets into network than required. We can say a sender is overstating its path congestion and refer to this as a positive flow.
Today an effective and flexible congestion control of data traffic within wireless networks is not known, so that network resource utilization is not optimized within such wireless networks.
Thus, it is an object of the present invention to improve and further develop a method for resource management within a wireless network and an according wireless network for allowing a very effective resource management and network utilization.